Users of both voice-centric (telephone-like) and non-voice services, such as text communication for hearing-disabled users, expect to be able to initiate a request for help in case of an emergency. Unfortunately, the existing mechanisms to support emergency calls that have evolved within the public circuit-switched telephone network (PSTN) are not appropriate to handle evolving IP-based voice, text, and real-time multimedia communications. It is desirable to provide emergency call services which, at a minimum, offer the same functionality as existing PSTN services, with the additional non-limiting benefit of making emergency calling more robust, less costly to implement, and multimedia-capable. An IP-based end system and network element included in the system are described in The Internet Engineering Task Force RFC5012 entitled “Requirements for Emergency Context Resolution with Internet Technologies” published in January 2008.
Call routing entities are included in the IP-based system. The IP-based system is sometimes referred to as Emergency Services IP Network or ESInet. A call may be received from a source device (e.g., smartphone, telephone, computer, etc.) and eventually routed to an emergency services operator. One call routing entity is the Emergency Service Routing Proxy (ESRP). An ESRP is an emergency call routing support entity that may invoke the location-to-public service answering point (PSAP) URI mapping function. Due in part to the distributed nature of the evolving communications networks, a key feature for an emergency call is routing the call to an answering point that can provide emergency assistance to the location of the emergency. The ESRP plays an integral role in receiving a call and mapping the call to an appropriate PSAP URI or to the URI for another ESRP where subsequent mapping is performed. Call mapping may also be performed by other entities, including entities that instantiate the session initiation protocol (SIP) proxy role and the SIP user agent client role.
An ESRP may be selected for call routing based on location information included in the call. When the call is received by the ESRP, an emergency call routing function (ECRF) may be queried by the ESRP to identify the next hop for the call. In some implementations, a location information service (LIS) may be included to assist in generating or enhancing the location information for a call. To ensure routing to the entity responsible for the location of the call, location information may be updated (e.g., via LIS) just prior to querying the ECRF to ensure the most recent location information is used as the basis for the hop identification. This process may be repeated for several ESRPs until the final hop identified is a PSAP. In current implementations, each ESRP is an individual server identified using a single URI.
The clustering of the policy and routing function for an emergency call once received at an answering point has been described in U.S. patent application Ser. No. 14/058,049 entitled “Clustered Session Management.” In the present application, the ESRP is configured to determine which answering point should receive the call.
The routing and performance of an ESInet may be limited by the performance and scalability of the ESRP and the processing functions of the ESRP. Although routing and policies are put in place for distributing the calls across the network, the ESRP is still bound by the physical limits of its underlying infrastructure. This can cause calls to be routed inappropriately to destinations due to these limits. Latency in the ESRP can cause degraded service to users due to routing decisions based on upstream policies even if there are agents and handling capabilities in the PSAP calls may be redirected due to performance limitations of the ESRP.
As discussed, a call may be routed via a chain of two or more ESRPs. In such instances, the issues of performance and scalability may be experienced most severely in the terminating ESRP which generally refers to the ESRP at the end of the chain. For example, the terminating ESRP incurs the processing overhead of its predecessor ESRP(s) such as agent logic and control functions applied as the call winds its way through the system.
Ensuring the efficient and fault tolerant of the routing of calls to a PSAP can, particularly in emergency situations, make the difference between life and death.